<?php
/**
 * <https://y.st./>
 * Copyright © 2015 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => 'A new onion address format?',
	'<{body}>' => <<<END
<p>
	Marc With A C&apos;s <a href="https://marcwithac.bandcamp.com/album/lifes-so-hard">bonus albums</a> came by email late last night, but mainly, I have only listened to the introduction of one and a single song on another.
	One of these albums is a recording of a live show though, and his live shows always seem fun.
</p>
<p>
	First Tech Federal Credit Union sent me an email this morning telling me once again that they will be sending me a replacement debit card in the mail.
	I hope they sent it to my current address and not my former address.
	Their first letter about the new debit card was sent via paper mail to my former address, despite my having updated my address in their records.
	The email continued that the card must be activated by telephone though.
	If the card comes to my current address, I will pester them about the issue right away online, explaining that I have no telephone to call from.
	If they send it to my former address, I will wait several months until the next time I am in Springfield, then pester them about it in person.
	Then I will pester them about the fact that they are still sending my mail to my former residence instead of my current one.
</p>
<p>
	Vanessa, Cyrus, our mother, and I went to the coast as planned, but our mother seemed irritable all day.
	She kept picking stupid fights with us over petty things, then would act put off when we did not agree that she was right for having done so.
	On the way back home, we stopped at a discount store, and when the person running the till asked her to start putting the merchandise on the conveyor, it ticked her off.
	Just to be petty, she unloaded each can individually instead of leaving them in the boxes that hold a dozen cans each for the sole purpose of making the checker bag eaxh can, despite the fact that she knew leaving the cans in the box would make them easier to deal with both for the checker and for us when we got them home.
	And that is not to mention the fact that the extra bags were a waste of plastic.
</p>
<p>
	<a href="https://wowana.me/">Wowaname</a> suggested that I might like the artist <a href="https://tesslesstess.bandcamp.com/">Tesslesstess</a>.
	She is pretty good, too! I was going to buy some of her work later once I have found a job, but I accedentally purchased <a href="https://tesslesstess.bandcamp.com/album/the-pre-industrial-town-mill-wheels">The pre​-​industrial town mill​-​wheels</a>, thinking that I had <a href="http://professorshyguy.bandcamp.com/album/fragmentation">Fragmentation</a> in my cart, finally without sales tax.
	I must have put &quot;The pre​-​industrial town mill​-​wheels&quot; in my cart to see if that would have sales tax, as only Professor Shyguy&apos;s work seems to have this issue, at least both today and yesterday.
	I later also noticed that if I had ordered the physical casset copy of &quot;The pre​-​industrial town mill​-​wheels&quot;, I would have gotten some bonus music on the take itself, which may or may not have been worth the while.
	I do not currently have the equipment to rip a cassette tape back into something digital, but I might in the future.
	I eventually did get Fragmentation preordered, but only as I was heading off to bed.
</p>
<p>
	Wowaname sugested that I use <code>&lt;pre/&gt;</code> tags on my <a href="/en/weblog/2015/">weblog index page</a> and remove the <code>&lt;br/&gt;</code> tags, though i was reluctant to do that at first.
	Until now, I have been avoiding using that tag in most places because it seems like the easy way to do things, not the <strong>*right*</strong> way to do things.
	But the fact is, the <code>&lt;pre/&gt;</code> tag has semantic value.
	My $a[ASCII] calendars on that page do not function well in a variable-width font because they are meant to be displayed in a fixed-width font; this is exactly the type of data the <code>&lt;pre/&gt;</code> tag was meant to denote.
	On the other hand, I used that same tag on my <a href="/en/URI_research/usable_ccTLDs.xhtml">usable $a[ccTLD]s page</a> as a bandage so I would not have to figure out how to format the data until I had all the data I planned to put there, but before I had even completed the page, I had decided to replace it with a <a href="/en/URI_research/best_ccTLDs.xhtml">more detailed page displaying only information on the best of the best $a[ccTLD]s</a>.
	I kept the old page, but because I had half-abandoned it, I never went back and fixed the problem even though I had finished the research and added all the relevant data to the page.
	I took this opportunity to clean up that page as well.
</p>
<p>
	I am really liking the idea of the Ricochet instant messaging setup as a replacement for TorChat.
	The main advantage I see is that if you look at the <a href="https://ricochet.im/">Ricochet website</a>, the example Ricochet address given is <code>ricochet:rs7ce36jsj24ogfw</code>.
	The colon makes it look like a linkable $a[URI].
	If that truly is the case that Ricochet uses $a[URI]s with a $a[URI] scheme that can be set to open in the Ricochet application, the ease of reaching people that publish their chat handles properly should be easier.
	Instead of people having to copy and paste the second level of my onion domain into their chat clients, they can simply click a link that i have set up! However, there are issues.
	Like TorChat, Ricochet is built to use a portable copy of $a[Tor] instead of the system-wide installed copy of $a[Tor].
	As two $a[Tor] instances cannot share an onion address, this means that you need a dedicated onion address for Ricochet and cannot have your Ricochet handle match your Web address.
	The Debian packaged version of TorChat uses the system-wide copy of $a[Tor] though, even if it does start a second instance of it.
	This is likely because when TorChat is installed globally, it does not make sense for it to use a dedicated copy of the $a[Tor] software.
	Messing with the TorChat scripts a bit, it is even possible to make TorChat depend on the main running instance of $a[Tor] and not start a new one.
	The way I see it, it is highly likely that the Debian packaged version of Ricochet has similar properties, but as Ricochet is fairly new software, it exists only in Debian Unstable.
</p>
<p>
	I did not want to upgrade <a href="/en/domains/newdawn.local.xhtml">newdawn</a> to the unstable version of the operating system without knowing for sure that doing so would help me make Ricochet do what I wanted it to, so I tried installing Debian Unstable in a hypervisor for testing.
	The <a href="https://wiki.debian.org/InstallFAQ#Q._How_do_I_install_.22unstable.22_.28.22sid.22.29.3F">instructions for installing Debian Unstable</a> say to start by installing Debian Stable, then upgrade.
	The installation of Stable went fine, but when I changed the sources to point at the Unstable repositories and performed a dist-upgrade, the system ran into issues near the end.
	After all the software had been downloaded and a large chunk of it had been set up, the system suddenly decided that the file system was read-only.
	No more changes could be made.
	I tried shutting down the system, but the system locked up.
	After forcing the virtual machine to abort then restarting it, the system complained of file system damage and said that the file system needed to manually have fsck run on it.
	I do not need a system that is going to break before I can even get it set up!
</p>
<p>
	I later realized that things might have gone differently, had I tried to do this on real hardware instead of in a hypervisor.
	I have to know for sure if this would go better, so tomorrow, I will swap the hard drive out, so I will not lose my current system, and install Debian to the new drive to try this again.
</p>
<p>
	On <a href="ircs://irc.volatile.ch:6697/%23Volatile">#Volatile</a>, devnull explained to me a bit how $a[I2P]&apos;s equivalent to $a[IP] addresses work.
	The main addresses are in base sixty-four, but a shorter hostname can be found by taking the $a[SHA256] hash of the main address, encoding it in base thirty-two, and appending <code>.b32.i2p</code>.
	The $a[I2P] website <a href="https://geti2p.net/en/docs/naming#base32">compares these host names to $a[Tor]&apos;s onion addresses</a>, but also links to a page on the $a[Tor] website explaining how <a href="https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-december-4th-2013">onion addresses may become even more like $a[I2P] hostnames</a>.
	The article is two years old, so I do not know if this plan is still in the works, but the idea was that $a[Tor] would begin using a full $a[SHA256] hash, instead of the truncated $a[SHA1] hash that it uses now.
	If this were to happen, I have no idea if current onion addresses would continue working.
	It is possible that the two onion address formats would work in tandem, with the format of the onion address being determined on the publishing side by the presence or lack of presence of some new variable and on the resolution side by the length of the domain&apos;s second-level label.
	However, it seems just as likely that the new onion address format would completely replace the old onion address format, either making old onion keys unusable or making them produce onion addresses in the new format.
	Either way, if old onion addresses no longer function, hyperlinks all across onion space would break.
	And what about TorChat and Ricochet? Would they function with longer onion addresses as they are, or would they need to be updated before they could accept chat handles based on the new onion addresses? Also, last time I checked, eschalot was unmaintained.
	How long would it be until a custom onion address generator was built that takes the new onion address format into account?
</p>
<p>
	My <a href="/a/canary.txt">canary</a> still sings the tune of freedom and transparency.
</p>
END
);
